[% setvar title The Perl 6 Summary for the week ending 20021027 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20021027'></a><h1>The Perl 6 Summary for the week ending 20021027</h1>
<p>You may have noticed that this summary is late. Um... [looks sheepish,
shuffles feet], the dog ate my homework. I did a tiny bit of
procrastination at the beginning of the week and then got totally
overtaken by events involving failed AC adaptors and general
confusion. Sorry folks, it will probably happen again, but hopefully
not in the near future.</p>
<p>So, kicking off, as is customary, with perl6-internals before getting
down to attempting to summarize the monster that was perl6-language:</p>
<a name='C# and Parrot'></a><h2>C# and Parrot</h2>
<p>The dialogue with Rhys Weatherley and Gopal V from the DotGNU project
continues apace, mostly to do with clarifying what C# needs in the way
of datatypes and the like. It appears that Leon Brocard is the go to
guy if you need to know the exact details of almost anything in a
language spec. Maybe he's just really good with Google.</p>
<p>Gopal V wondered if there was someone involved in p5i who would mind
acting as a liaison with the DotGNU people, who could give them a heads
up when, say, the packfile format changed. Leopold Toetsch wondered
what sort of changes were potential C# breakers, as there were
probably things that we thought of as `internal' that the C# team
could be depending on. Leo also thought that the liaison person should
probably be Dan.</p>
<p><a href='http://groups.google.com/groups?threadm=20021026223952.A6708@md3.vsnl.net.in' target='_blank'>groups.google.com</a></p>
<a name='Scratchpad confusion'></a><h2>Scratchpad confusion</h2>
<p>At the end of last week, Allen Short pointed out some discrepancies
between the implementation of scratchpads and the description of them
in PDD6. John Sillito reckoned that PDD6 was waiting on a rewrite from
Dan, especially where Scratchpad PMCs were concerned as there were a
couple of different patches waiting on Dan's say so. Dan also offered
some clarification, but hasn't ruled on the Scratchpad PMCs yet.</p>
<p><a href='http://groups.google.com/groups?threadm=20021020.165144.233688742.washort@twistedmatrix.com' target='_blank'>groups.google.com</a></p>
<a name='Help! Bugs! Crawling all over me! OR The road to 0.0.9'></a><h2>Help! Bugs! Crawling all over me! OR The road to 0.0.9</h2>
<p>Steve Fink wants the GC bugs ironed out before he goes adding much in
the way of new features, and he wants to start putting together a
0.0.9 with working GC too. To that end he deliberately broke all
the tests by turning GC_DEBUG on for tests. There's a certain amount
of cleverness involved in how he did this; read his post if you're
interested. Peter Gibbs found what he thought was a fix for a couple
of the failures and pointed to the possibility of a fundamental
problem in MultiArray as the culprit for the remaining failure. Steve
applied this patch with much rejoicing, and then came up with a trial
patch that seemed to fix the multiarray triggered failure. This patch
had not been finalized by the end of the week.</p>
<p>Steve also kicked off discussion of the forthcoming 0.0.9 release,
when he posted his list of prerequisites and sparked off a decent
amount of discussion of various points. Steve's overarching goal for
this release appears to be 'bug reduction and general consolidation'.</p>
<p><a href='http://groups.google.com/groups?threadm=20021021085217.GH2030@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021023162722.GI2103@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a></p>
<a name='Keyed ops, the return.'></a><h2>Keyed ops, the return.</h2>
<p>I think it's safe to say that some people aren't entirely happy with
keyed ops as they stand now in Parrot. The week before, Leopold
Toetsch had written a proposal for keyed ops. This week he supplied a
proof of concept patch. J&uuml;rgen B&ouml;mmels liked it but Dan
took a little more convincing. I'm not sure he is entirely convinced
yet, but he's willing to live with it.</p>
<p><a href='http://groups.google.com/groups?threadm=3DB4216B.1080409@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='64-bit ints and non-capable hardware'></a><h2>64-bit ints and non-capable hardware</h2>
<p>Dan announced that he was about to bite the bullet and declare that
INTVALS have to be 64 bit integers and wanted to know of any
(plausible) platforms that have neither native nor emulated 64 bit
integers. Martin D Kealey pointed at what sounds like a scary proposal
from C99 involving declarations and clever compilers and wondered if
it might be a way forward for parrot. Rhys wondered how well the idea
would play with something as dynamic as Parrot and the languages
expected to run on it, but Martin didn't seem to think it would be
much of a problem.</p>
<p><a href='http://groups.google.com/groups?threadm=a05111b0db9da0181ab77@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/' target='_blank'>wwwold.dkuug.dk</a></p>
<a name='Configuring and DOD'></a><h2>Configuring and DOD</h2>
<p>Erik Lechak couldn't get the latest parrot to build on WinXP. Josh
Wilmes diagnosed a problem with the way the configuration tools probed
for stack direction, and patched things so that stack direction
detection was done at runtime once more. Jason Gloudon, who had moved
the detection phase out into configuration time wasn't sure that this
was a good idea 'cos it would lead to a performance hit in the stack
walking code. Nicholas Clark, with his clever head on, came up with
three different ways of doing things at runtime without a performance
hit, and Dan blessed the third choice.</p>
<p><a href='http://groups.google.com/groups?threadm=200210240323.g9O3NQN3010652@galactic.hitchhiker.org' target='_blank'>groups.google.com</a></p>
<a name='Execute in place?'></a><h2>Execute in place?</h2>
<p>Rhys Weatherley has been taking a look at our packfile format code,
and thinks it could be improved by designing the format in such a way
that it can be <code>mmap</code>ped into a block of memory and executed immediately,
as opposed to the way parrot currently does it, which involves moving
stuff around in memory before starting execution. Dan said that that's
how things were originally done, and if it wasn't still possible then
that was a bug.</p>
<p><a href='http://groups.google.com/groups?threadm=3DB927BB.8D19D9C9@zip.com.au' target='_blank'>groups.google.com</a></p>
<a name='Copyright notices and license stuff'></a><h2>Copyright notices and license stuff</h2>
<p>Towards the end of the week, Dan announced that he was about to
straighten out the copyright and licensing situation. As a first
step, would be marking everything in the core as Copyright YAS. It
looks like Parrot itself will be moving to an MIT style license `Over
no objections whatsoever from the FSF'.</p>
<p>If you've made any contributions to Parrot's code base then you've
probably already been contacted, but if you haven't and have an
objection, you should contact Dan.</p>
<p>Most of the discussion of this happened in the next week, and I'll
return to it in my next summary, but response was generally favourable
following some clarifications from Dan.</p>
<p><a href='http://groups.google.com/groups?threadm=a05111b13b9e097305b07@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Allow a NULL interpreter in sprintf like functions'></a><h2>Allow a NULL interpreter in <code>sprintf</code> like functions</h2>
<p>J&uuml;rgen B&ouml;mmels sent in a patch which allowed the use of a
NULL interpreter in <code>sprintf</code> like functions. Leo Toetsch applied it,
but wondered if it was actually the Right Thing. Dan seemed to think
that, in the long run, it probably wasn't and that, if something went
horribly wrong before an interpreter got properly set up then it was
probably best to use the standard library functions.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-18097-40584.7.52416404410681@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05111b23b9e1be83d6b3@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Draft sketch of bytecode generation'></a><h2>Draft sketch of bytecode generation</h2>
<p>Dan offered a `<i>very</i> sketchy' draft of his thoughts on what we need
from our bytecode generation system. Initial reaction seemed positive.</p>
<p><a href='http://groups.google.com/groups?threadm=a05111b25b9e1ca2991c4@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Won't someone please think of the summarizer?'></a><h2>Won't someone <i>please</i> think of the summarizer?</h2>
<p>There were around 150 messages in perl6-language this week. The *vast*
majority of them discussing the Perl 6 built in operator list. It all
started weeks ago, when Damian wanted <code>|</code>, <code>&amp;</code> and
<code>the_as_yet_unnamed_xor_operator</code> as superposition generating
operators. But that meant we'd need somewhere else to put the bitwise
operators. And people like <code>^</code> as xor, but that's not very possible
because of hyper ops. And <i>nobody</i> likes <code>_</code> as a concatenation
operator. It's all got very complicated.</p>
<p>However, in answer to a summarizer's prayer, Michael Lazzaro has taken
to posting a scorecard of his understanding of what the current list
of built in ops is. (A list of diffs between these would be interesting
to see...). Things that appear to be set in stone:</p>
<ul>
<li><a name='~ is the new _, which was the new . and which nobody liked.'></a><code>~</code> is the new <code>_</code>, which was the new <code>.</code> and which nobody liked.</li>
<li><a name='~~ is the new =~. (Otherwise =~ -&gt; match, and ~= -&gt; string append could get somewhat confused...) !~ stays the same.'></a><code>~~</code> is the new <code>=~</code>. (Otherwise <code>=~</code> -&gt; match, and <code>~=</code>
-&gt; string append could get somewhat confused...) <code>!~</code> stays the same.</li>
<li><a name='| and &amp; make any and all type superpositions, respectively. Damian has an article on why superpositions are such a good idea forthcoming for perl.com. The phrase `in constant time' will probably not be used.'></a><code>|</code> and <code>&amp;</code> make <code>any</code> and <code>all</code> type superpositions,
respectively. Damian has an article on why superpositions are such a
good idea forthcoming for perl.com. The phrase `in constant time' will
probably not be used.</li>
<li><a name='Nobody has any idea what xor will end up as.'></a>Nobody has any idea what xor will end up as.</li>
<li><a name='Some people are worried that changing things too radically from old Perl/Algol type syntax will make for a harder learning curve. Other people tend to think that not many programmers use bitwise ops in Perl at the moment, so the change shouldn't matter too much.'></a>Some people are worried that changing things too radically from old
Perl/Algol type syntax will make for a harder learning curve. Other people
tend to think that not many programmers use bitwise ops in Perl at the
moment, so the change shouldn't matter too much.</li>
<li><a name='It's a real shame that so many Unicode characters are so hard to type.'></a>It's a real shame that so many Unicode characters are so hard to type.</li>
</ul>
<p>Here's a list of Michael's various opcode lists. They're usually good
entry points to the discussion. (Which is kind of fascinating...)</p>
<p><a href='http://groups.google.com/groups?threadm=7A748E43-E847-11D6-A7D4-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=F574FCCE-E86E-11D6-A7D4-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DBC5347.6DB387E4@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Character properties'></a><h2>Character properties</h2>
<p>Luke Palmer wondered if we were planning on having properties on
individual characters on a string; something he felt was an essential
feature. There was a certain amount of debate about the use of the
word `essential' in this context, leading Luke to give some more
information about what he was driving at before he was eventually
persuaded that what he wanted was an ideal candidate for a module.</p>
<p><a href='http://groups.google.com/groups?threadm=20021021050943.9C0E9287@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021021202056.DCECF289@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Perl6 Built in types'></a><h2>Perl6 Built in types</h2>
<p>Michael Lazzaro asked for a list of Perl6 built in types and offered
his own first cut at such a list. Larry offered some corrections, but
reckoned that the list Michael had just posted was the nearest thing
we had to a definitive list.</p>
<p><a href='http://groups.google.com/groups?threadm=EF53A634-E6B1-11D6-A0A5-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Power of Lisp macros'></a><h2>Power of Lisp macros</h2>
<p>Adriano Nagelschmidt has been reading Paul Graham's articles about
Lisp and its advantages, especially the macro system and wanted to
know if the macros were really as useful as Mr Graham claimed, and
whether it was worth adding something like them to Perl. General
consensus appears to be &quot;Yes, they're really good, and yes, Perl 6
will probably have something similar&quot;. Larry had an interesting post
on the subject (no surprise there then...)</p>
<p><a href='http://groups.google.com/groups?threadm=20021023214308.GA746@chianti' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.paulgraham.com' target='_blank'>www.paulgraham.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.44.0210250839030.17544-100000@london.wall.org' target='_blank'>groups.google.com</a></p>
<a name='In Brief'></a><h1>In Brief</h1>
<p>There was a minor kerfuffle early in the week when the Parrot CVS
repository ended up with the wrong permissions. Oops.</p>
<p>Leopold Toetsch has implemented the <code>splice</code> vtable method based on
the semantics in PDD2. This sparked a short discussion about copying
vs.  cloning.</p>
<p>It looks like native types are going to get type numbers just like
PMCs, but native types will be negative.</p>
<p>Rhys Weatherley added a bunch of infix operators to IMCC's syntax.</p>
<p>J&uuml;rgen B&ouml;mmels added `fingerprinting' to .PBC files. The
idea being that parrot can fail at load time if it tries to load a
..PBC file that was generated with a different version of
<b><i>core.ops</i></b>. The previous behaviour involved weird, hard to track
down, runtime errors.</p>
<p>Some spam got past the perl6-internals filters. We were shocked.</p>
<p>Michael Lazzaro announced an updated Perl6 OO Cookbook at
<a href='http://cog.cognitivity.com/perl6/.' target='_blank'>cog.cognitivity.com</a></p>
<a name='Who's who in Perl 6?'></a><h1>Who's who in Perl 6?</h1>
<p>Apparently nobody is this week. I appear to have run out of answer
sets for the questionnaire. If you've been mentioned in this, or any
previous summary and you've not already answered, please drop me a
line and I'll send you the questions.</p>
<a name='Acknowledgement, Apologies and all that Good Stuff'></a><h1>Acknowledgement, Apologies and all that Good Stuff</h1>
<p>This summary was once again brought to you from my office on board the
0625 from Newark to London and from my comfy chair at
home. Distractions were provided by Xmame, Perls of the North, broken
AC Adaptors and my own natural `Procrastinate now!' instincts.</p>
<p>Proofreading services were provided by me. Having left it as late as I
did, I just want to get this summary out of the door before next
week's is due. So any speeling mistooks are orl myne.</p>
<p>And, the old refrain: If you enjoyed this summary, please consider one
or both of the following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ where your money will be used to support the ongoing development of Perl and Perl 6.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> where your money will be used to
support the ongoing development of Perl and Perl 6.</li>
<li><a name='Send feedback, flames and/or an original BeBox to me, mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a>'></a>Send feedback, flames and/or an original BeBox to me,
mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a></li>
</ul>
<p>Any fee paid for publication of these summaries on perl.com is paid
directly to the Perl Foundation.</p>
</div>
